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(54) Title: NATIONAL CUSTOMER RECOGNITION SYSTEM AND METHOD 
{57} Abstract 



A system and method for implementing a customer tracking and recognition program that encompasses customers' gaming and non 
gaming activity alike at a plurality of affiliated casino properties. Customer information is accumulated at each affiliated casino through 
one or more LAN-oased management systems, updated to a centra! patron database (CPOB) that is coupied to each casino LAN through a 
WAN, and made available to each affiliated casino property as needed. Customer accounts are automatically activated and provided with 
data from the CPDB when a customer from one casino property first visits an affiliated casino pioperty. Customer accounts are updated 
with new activity data whenever a management system associated with the casino receives customer data from input devices, such as cart! 
readers, workstation;;, and dumb terminals, located at various venues throughout the casino. Customers are awarded points, based on their 
tracked activity at al! affiliated casino properties. The point awards have a monetary value and are redeemable for gifts, meal*, cash and the 
like, at any of the casino properties. The point awards may embody different promotional schemes in which point awards arc adjusted to 
target different casino properties or different venues within a casino. Summary customer data, including point levels, is regularly updated 
to reflect ongoing customer activity at the- casino property. This Jaf3 is made available to employees at arty affiliated casino property, as 
needed, to personalize customer services. 
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NATIONAL CUSTOMER RECOGNITION SYSTEM AND METHOD 
Background of the invention 

Tech iw& Yield I his. mvertiun relates to the field of systems foi tucking customs! 
activity at *.asinos, and in naiticuiai, to systems tor tracking customers' gaming and non-gaming 
5 Activity act oss affiliated casino ptoperties, ki use m customer lecogmtion and maix.etmg 
programs. 

Background A,rt Substantially ail casinos have implemented some fonn of customer 
tracking to identify anc lev-anl their valuable customers. These tracking progutr s ot;en use tht 
betting activity o! a customer as the basis foi awarding the customer complementary, looms, 

10 meals, e\ent ticket-., ana the like ( Yomps" ) i j ptcaJly. these tracking programs are 

implemented bv providing each customet with a casmo memoes ship card v hieh inc uaes a 
machine readable identification number spe.'ihc to the customer bach identification number 
has an associated iJistnmei account that js s'oted in tht- casino s . onputei vy^uu and apdated 
to reiiect customer ^tivrty Customeis need only insert their cardt, in slot machir.es oi card 

15 readers associated with gaming tables or gne their cards, to a casino employee to have their 
betting acmuv monitored anc 1 reflected in their accounts Customer eaids mav also be u,sed to 
tracts customei activity a: casino venues, such as special cents showrooms, and hoteK, th ough 
cart; itaders and Lomputer terminals manned by casino employees 

The growt,\ of the gamirg industiy ha* created new challenges to the v>a\ 11 which 
20 customer tracking programs are implemented Man) sta r es and tenuoncs have .evcnti\ 
legalized casim' gambling, and companies have built casino propeit es at these rev, gaining 
locations to meet the demand fot gaming fac Jities Despite the mcieased mimbei of casmo 
properties aiiiitated w ith a company conventional casino management practices eonumit. to 
ticat these casino nropeittes as autonomous, decentralized entities that compete with each other 
25 foi v aluablc customers in patticulat, customer tracking at each casino propem is t/piraiiy 
conti oiled by local management and tew d any attempts have heen made to contd.nate 
customer information across affiliated casino properties For e\ample, each easmo has sts own 
vysicm that tracks octling dau. on the casinos customers 7 he prupntj treats t'ns betting data 
as confidential, at oidei to prevent competing casinos, including those affiliated with the 
30 ptoperty, from luring away valuable customers Thus, customer tracking programs ai affiliated 
properties remain f-agmented, and conventional management practices provide little incentive 
to coordinate data accumulated by these tracking programs 

bven if a easmo company was to attempt some coordination of customer !ra>Amg 
programs at its iff tiiated Casmos, the systems cut tenth m phce at vauous casino ptoperties are 
35 too iocalued to mtCLrate eas-ily Ca»mo management systems are tvpicalh custom dt S'grcd toi 
each casino niopon the customei data is limited tc selected customei acfvity at Jit spe^ilu. 
casino property, anc the customer data accumulated by different compjter systems withm the 
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same casino is often in different, incompatible formats. Thus, while each casino has useful data 
for its regular customers, there ts no ready means for consolidating Shis data or making it 
available conveniently for use at other casinos. In short, there are both operational and 
technical barriers to coordinating customer tracking programs at individual casino properties 
into national, company-wide tracking and marketing programs. 



Summary of the Invention 

The present invention is a system and method for implementing a customer tracking and 
recognition program that encompasses customers' gaming and non-gaming activity alike at all 
casino properties affiliated with a casino company. Customer information is input to a 
management system associated with each affiliated casino property, updated to a patron 
database, and made available to each casino property as needed. This provides casino 
employees at each property with on-line access to the customer data necessary to implement 
cross-property incentive programs and to provide personalized services to customers, 
independent of which casino property the customer regularly visits. Marketing personnel have 
access to a more complete database of customer activity for developing and monitoring 
marketing programs, including offer management and redemption programs. The present 
invention allows customer data to be accumulated across ail casino properties and made 
available at any casino property without overburdening I he individual casino properties' 
computer systems with unnecessary data. 

A system in accordance with the present invention comprises a local area network 
(LAN) at each affiliated casino property and a wide area network (WAN) for coupling data 
among the casino LANs. A management system associated with each casino LAN receives 
customer data from card readers, workstations, and dumb terminals, located at various venues 
throughout the casino and couples the received data to a database that is accessible to all 
affiliated casino properties. In a preferred embodiment of the invention, a centra! patron 
database (CPDB) comprising customer accounts from all of the casino properties is supported 
on a central LAN that is coupled to the casino LANs through the WAN. In this embodiment, 
the management system may be a single, centralized system supported on the central LAN, a 
distributed system comprising local management systems associated with each casino LAN, or 
a hybrid system including both centralized and distributed components. The preferred 
configuration for the management system will depend on the data capacity of the WAN and the 
sues of She various casino properties. 

In the preferred embodiment of She invention, the management system further comprises 
a casino management system to handle, the day to day gaming transactions at various casino 
venues and hotel and event management systems to handle transactions relating to lodging and 
events, respectively. Data accumulated by the management, system is updated to the CPDB. 
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where it may be accessed by personnel at any of the casino properties through the WAN. When 
customer information is required at a casino property, the management system first checks 3 
data store associated with the property, and if the data is not available there, U is retrieved from 
the CPDB. On-line access to a customer's activities at ail of its casino properties allows the 
5 casino company to implement cross-property incentive programs, manage customer offer 
programs more effectively, and provide more personalized services to its customers. Data is 
available for a customer's gaming and non-gaming activities, giving the casino a more complete 
pkauie of the customer's expenditures while at the casino. 

For example, the system of the present invention facilitates and expands coniping. By 
10 tracking customers' gaming activities at all of the company's casino properties, the present 
invention provides more complete data on which to base comps and provides the same, 
complete data to each casino employee, regardless of how frequently the customer visits their 
property. This allows valued customers to be recognized at any casmo property affiliated with 
the company, regardless of which casino they patronize regularly. It also makes comping more 
15 consistent across different casino properties. 

In addition to comping, the present invention implements a point system that awards 
points to customers based on their tracked activity at all casino properties. Customer points 
earned at any of the affiliated casino properties may be redeemed for gifts or services at any of 
the affiliated casino properties. In effect, a customer's points represent a monetary value of the 

20 customer's activity, and may be used in place of cash at any affiliated casino, independent of 
where the points were earned. The point system may be used to target various properties or 
venues by weighting point awards according to the venue, the time period, or the casino 
property at which the points are generated. This allows new casino properties or venues at 
existing casino properties to be promoted by awarding extra points to customers who visit the 

25 targeted property or venue. 

The term "affiliated casinos", as it is used throughout this disclosure, is intended to 
indicate any of a number of different relationships between casino properties. For example, 
casinos may be affiliated through common ownership by a parent company, they may be owned 
by different companies operating under a cooperation agreement, or they may be under contract 
30 with the same provider for customer tracking services. 

Brief Description of the Drawings 

Fig, I is an overview of a national customer recognition system in accordance with the 
35 present invention. 
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Fig-> 2A. 2B f and 20 are block diagrams of the various system modules supported in the 
central database server and a casino proper*} LAN respectsveh . for different configurations oi 
the customer recognition s\stem 

Fig 3 is an overview of a casino LAN, indicating urmections between the vanou> input 
*5 dev ices and distributed management systems sapported on the casino LAN 

fig 4 is a. flaw char: lepresentmg a method ior tracking customei activity across ail 
affiliated casino pioperties in accordance with the piesen. invention 

Fig 5 is a block diagiam ol the system module*- supported on casino 1 ,ANs wtiere a 
distributed patron database and management systems ais employed 

10 

Detailed Description of the Invention 

The present invention i> described m detail fui a configuration of ihe national customer 
recognition system comprising a central patron database (CPDB) on a central LAN thai is 
coupled to local management systems associated with eadi casino LAN Tms configuration ss 

1 5 particularly useful for companies thai have already invested significant capital nt lucal 
management systems for their casino pi jpeities, bt cause it levfr?ges these systems into a 
company-w ide network through the addttior of a CPDB The s\ stem confirm atton employing 
a centralized management system with a CPDB and the sysjem t onl ft ra v inn employing 
di&tuhuted management and database systems are discussed in conjunction with Figs 1C and \ 

20 respectively. 

Rdernng tirsr to Fig 1 , there is s how n an ova view of a computer network 100 f oi 
implementing the system and method of the pit-sent invention Computer system 100 is .shown 
comprising a central database LAN i 10 and casmo LANs I20t l)-120<n), each of which is 
associated with on^ of the affiliated casino properties Centtal database LAN 1 10 and casino 
25 LANs 120(1)- 12001) are coupled through a wide areanetwoik (WAN) 102 Typically, centiat 
database LAN 1 10 wiH be located at a tential facility oi the casino company 

in the following discussion, I AN 1 20 designates any <>ne of casino LANs 1 20(. 1 )- 1 20in) 
unless <»therw ise noted Similar notation, ..c. umndeKed reference numbers, ts used tor the 
various components of LANs 120(1 H20(n) it is understood tnat in a typical application, 
30 computer system 500 includes one or more LANs 1 20 for each i asino property attiltateri with 
the patent casino company, and ail LANs .20 communicate with cential database LAN 110 
through WAN 102 This configuration allows each LAN 110, 1 20 to operate in a substantial 1 .) 
independent manner until it requires acetss to data available on a different network 

In the disclosed embodiment, central <. at abase LA.N 1 10 comprises an ethernet lOo to 
^5 which a centiai database server 1 1 2 and ,t marketing support servei 1 5 are connccicd An 
optional server 1 lo on LAN 1 30, supports a centralized management systeni (CMS 284, Fig 
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20 in the fully centralized configuration of the national customer recognition system. A token 
ring 1 08 is also shown connecting ethemet 106 to WAN 102. Token ring 108 typically includes 
additional nodes, such as workstation 1 IS, for marketing and local processing. Centra! 
database server ) 12 includes a central patron database (CPDB 220, Fig. 2 A), comprising 
5 customer accounts based on data originating at each casino property affiliated with the 
company. For the embodiment employing distributed management systems (CMS 234. Fig. 
2B), central database server 112 is the only essential node on LAN 1 10. However, it is likely 
thai in most implementations, other nodes such as workstations 11 Si and marketing support 
server 3 14 will be available for marketing analysis using data derived from CPDB 220. 

10 In the preferred embodiment of the invention, marketing support server 1 1 4 includes 

customer data from CPDB 220 stored in a manner that facilitates its use for marketing purposes. 
For example, customer data may be sorted and stored in server 1 14 according to customer 
groups segmented by profitability, principal gaming location (propertyl, or other maiketing 
criteria. On the other hand, customer data in server i 12 is stored in a manner that facilitates 

i 3 rapid access by customer T.D or name. 

Referring now to Fig. 2A, there is shown a block diagram of various systems supported 
on central database server 112. These include an operating system fOS) 212, a database 
management system (DBMS) 214, a transaction management system 216'. and central patron 
database tCPDB) 220, Transaction management system 216' supports messaging between 

20 casino LANs 120 and services on centra! LAN 1 10, such as CPDB 220, allowing them to 
exchange data as necessary. In the disclosed embodiment, central database server 112 is an 
NCR 3555 computer. OS 212 is Unix SVR4. DBMS 214 is Informix 7.1 , and transaction 
management system 216' is TOP END, available from AT&T/NCR. Centra! LAN 1 10 employs 
TCP/IP communication protocol for communications among the nodes of etherrset 106 and 

25 token ring 108. 

Referring again to Fig, 1 , each casino property LAN 1 20 is shown with the same basic 
structure. For purposes of illustration, LAN 120 is shown comprising a token ring 122 to which 
are connected computers 124, 144, 154, a gateway server 126, and workstations 128, 148. 
Dumb terminals 132 and PCs 172. which are connected directly to computer 124, are typically 
30 associated with gaming tables (Fig, 3), and slot machines 1 30 are coupled to computer 1 24 
through a slot computer 154 and token ring 122, Thus, all gaming-reiated activity is routed to 
computer 124, 

A person skilled in the art will recognize that LANs 120 associated with different 
properties may vary from this structure in order to accommodate special needs at different 
35 casino properties, without altering the nature of the present invention. For example, a casino 
property lacking a hotel or event venue would not include computer 144 or workstation 128 and 
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their associated lodging and event management systems, respectively. In addition, other LAN 
protocols, including ethernei and the like, may be used instead of token ring 122. 

Referring now to Fig. 2B, there is shown a detailed block diagram of LAN 120, 
indicating a casino management system (CMS) 234, lodging management system (IMS) 238, 
5 and event management system (EMS) 240. associated with various LAN nodes (computers J 24, 
144, and workstations 128, respectively), for monitoring, tracking, and controlling diffeient 
areas of casino operations. In a preferred embodiment of the invention, CMS 234 includes 
Report Program Generator <RPG)-based programs for on-line transaction processing (OLTP) 
applications. These applications consolidate activity data at the casino property related to 
iO gaming, and access CPDB 220 to retrieve or store data, as necessary. For example, dumb 

terminals 132 and PCs 1 72 communicate customer gaming activity data from gaming tables to 
CMS 234, Dumb terminals 132 and PCs 172 may also be used tor tracking customers' currency 
and marker transactions and for accessing gaming activity that is tracked through a slot 
computer 1.54. 

15 Automatic bet tracking at slot machines i 30 is monitored by a slot monitoring system 

(SMS) 262 on computer 154, which couples accumulated bet tracking data to CMS 234 through 
token ring 122. In the preferred embodiment, bet tracking is accomplished through a card 
reader fnot shown* associated with slot machine 130. A customer inserts his or her identity 
card in the card reader to initiate bet tracking and removes it to terminate bet tracking. A 

20 customer's betting activity at slot machine 130 is accumulated in SMS 262 until the session is 
terminated or an account stams is requested by CMS 234, at which time the data is transferred 
to CMS 234 via LAN 120. 

LAN 120 may optionally include a pit tracking system {PTS'i 258 to automatically track 
customer activity at gaming tables 134. PTS 258 is shown supported on a computer 174, which 
25 couples customer activity data to CMS 234 through LAN 120. ITS 258 uses card readers 

associated with player positions at gaming tables to track customers' betting activity. Estimates 
of betting activity are based on a player's time at a gaming table and the minimum bet at the 
table. Systems for automatically tracking betting activity at slot machines and gaming tables 
are well known in the art and are not described in greater detail here. 

30 In the preferred embodiment of the invention, a lodging management system (LMS) 238 

is maintained on computer 544. However, there is no reason that CMS 234, LMS 23S and any 
other management systems could not be supported on the same computer or some different 
combination of computers. LMS 238 comprises the software necessary for managing hotel 
operations within the casino, including reservations, room service, and other activities 

35 associated with hotel operations. In a preferred embodiment of the invention. LMS 238 

communicates with CMS 234 to search locally for selectee! customer information available on 
that system. However, LMS 238 may include its own local data store for customer data. 
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Also shown in Fig. 2B is an event management system (EMS') 240 on workstation 128 
and a restaurant/retail point of sale system (POS) 244 coupled to workstation !4S. EMS 240 
comprises software for handling ticketing information, reservations, and sales. POS 244 
comprises accounting software for operating restaurants and retail venues within the casino 
5 property as well as softw are for transmitting charge information to other management systems. 
For example, data relating to meals charged to rooms or redeemed meal conips are coupled 
from POS 244 to LMS 238 and CMS 234, respectively, through LAN 120. 

The primary role of gateway server 1 26 is to provide a fink between selected nodes of 
LAN 120 and central database server i 12 through WAN 102 and LAN 1 10. For this purpose, 

10 gateway server 1 26 includes a LAN/WAN interface 280 that, couples data packets between the 
communication protocols of LAN 120 and WAN 102 and another instance of transaction 
management system 256 that routes data packets between management systems 234. 238, 240 
and selected services in CPDB 220. In the preferred embodiment of the invention, CMS 234 on 
computer 124 accesses CPDB 220 through transaction management system 2! 6', 216, while 

15 LMS 238 and EMS 234 access CPDB 220 through CMS 234, as discussed below. An interface 
module 235 in CMS 234 provides communication links with transaction management system 
2 1 6, as discussed below. 

in the disclosed embodiment, of the invention, computers 1 24, 144 are IBM AS/400 
computers, computer 154 is an IBM RS6000. gateway server 126 is an NCR 3410, workstations 

20 1 28, 1 48 are based on '480 or better processors, and transaction management system 2 1 6, 21 6' 
is AT&T's TOP END. WAN 102 employs TCP/TP, an open communication protocol, while 
LANs 120 employ an IBM communication protocol, LU6.2. I.U6.2 allows direct 
communication between LAN nodes, but it is not the preferred protocol for communications on 
WAN 102. in the preferred embodiment of system 100, LAN/WAN interface 280 includes the 

25 software necessary to couple message packets between LU6.2 and TCP/IP protocols for 
communications between central LAN 1 .10 and casino property LANs 120. in particular, 
LANAVAN IF 280 operates in conjunction with transaction management system 216, 216 ! to 
provide CMS 234, LMS 238, and EMS 240 with rapid access to customer accounts for all 
customers who have visited any casino property affiliated with the casino company and 

30 obtained a customer ID card. For this purpose, each customer ID card includes a unique ID 
number that is associated with a customer account in CPDB 220. 

In the preferred embodiment of the invention, the RPG applications of CMS 234 are 
implemented in the AS400 environment of computer 124. In order to facilitate fast, real-time 
communication between CMS 234 and CPDB 220, a messaging system is implemented as part 
35 of interface module 235 of computer 1 24 and transaction management system 2 16' of server 
112. The messaging system functions as an application program interface (API) that allows the 
RPG applications of CMS 234 to communicate with CPDB 220 via transaction management 
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system 216, 216', with LAN WAN interface 280 coupling messages between the different 
communications protocols. 

in the preferred embodiment of system 100. customer data is transferred between LAN 
120 and LAN HO by means of message packets comprising header and data .segments, the 
5 attributes of which are specified in a data dictionary associated with the messaging system. The 
data segments reflect the database schema of CPDB 220 and the header segments correspond to 
user provided service applications (not shown) accessed through transaction management 
system 216, These user provided service applications implement functions for coupling data to 
and from CPDB 220 in response to requests from CMS 234. A utility associated with the 

10 messaging system reads the data dictionary and defines data structures in the AS400 system 
environment suitable for passing data between the RPG applications of CMS 234 and the 
messaging system. A message building/parsing module uses data provided through the defined 
data structures to build message packets for transmitting requests to transaction management 
system 216, 216', which directs the request to the appropriate, service application. A message. 

15 building/parsing module .associated with the service- applications provides analogous services 
for communications with DBMS 214. The messaging system is described in greater detail in 
Appendix A. 

As noted above, the optimal architecture for system 100 will be determined in part by 
the volume of data traffic that WAN 102 can handle, i.e. the "bandwidth" of WAN 102. The 

20 embodiment of Figs. 1 , 2 A, and 2B , in which each casino LAN 1 20 includes CMS 234 for 
handling day to day transactions and communicating data to CPDB 220, balances the 
advantages of centralized computing systems with the bandwidth limitations of typical WANs 
502. Where WAN 102 has sufficient bandwidth to handle real-time data transactions between 
CPDB 220 and a plurality of casino properties, local CMS 234 at each of the plurality of casino 

25 properties may be eliminated in favor of a centralized CMS 234 implemented on central LAN 

no. 

Referring now to Fig. 2C, there is shown a simplified block diagram of an alternative, 
centralized configuration for system 100. In the configuration of Fig. 2C, local CMSs 234 
associated with selected casino LANs 1 20' have been eliminated in favor of a centra! CMS 2S4 

30 supported on server 1 16 on central LAN 1 10. In this embodiment of the invention, each casino 
LAN 120' includes one or more computers 124' for communicating with centra! CMS 284 over 
WAN 102. Since computers 124' merely provide access to central CMS 284. they may be 
workstations or PCs. Central CMS 284 handles day to day transactions for each of casino 
LANs 120', maintaining a separate data store for each LAN 120' under its management. The 

35 data stores of centra! CMS 284 for LANs 1 20' are periodically updated to CPDB 220 to 

maintain the centralized data current. Where the data capacity of WAN 102 is sufficiently, it 
may be possible to eliminate local CMS 234 from all LANs 120, 120*. Similar hybrid and fully 
centralized configurations may also be set up for LMS 238 and EMS 240. 

8 
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Another alternative to the configurations of Fig. 2A, 2B, and 2C is a fully decentralized 
configuration in which CPDB 220 is eliminated in favor of a distributed database. This 
configuration is discussed in greater detail in conjunction with Fig. 5. Unless otherwise 
indicated, the following discussion assumes system 100 is configured as indicated in Figs. 2 A 
5 and 2B. 

Referring now to Fig. 3, there is shown the embodiment of system 100 including CPDB 
220 and local CMS 23-4, with communications links between different nodes explicitly 
indicated. In the disclosed embodiment, for example. CMS 234 receives customer activity 
input directly from gaming tables 134, kiosks 1 36, and a customer information center 138. 

10 CMS 234 also receives customer activity data from slots i 30 through SMS 262. Kiosks i 36 are 
terminate located around the casino property that allow customers to check on their activity 
point*, or camp availability by inserting their customer ID cards. Customer information center 
138 provides services to casino patrons such as membership information and arranging for 
"comps", as described in detail below. CMS 234 also provides data to each of these input 

15 devices. For example, casino employees at gaming tables 1 34 receive customer data summaries 
so they can determine whether the customer qualifies for a "comp' 1 or simply greet the customer 
by name. 

LMS 238 receives customer data from a hotel desk 178 and reservations clerks 
176 and provides customer account summaries to these locations for use by casino employees. 
20 EMS 240 also exchanges customer data with reservations clerks 176 and, in addition, 
exchanges customer data with events venues 174, 

In the disclosed embodiment, both LMS 238 and EMS 240 communicate with gateway 
server 126 through CMS 234, and gateway server 526 handles the data translation necessary io 
communicate with CPDB 220 via WAN 102. This communication topology facilitates 
25 searching among different management systems 234, 238, 240 for customer data, but it is not 
essential to the present invention. The same system could be operated with EMS 240 and LMS 
234 communicating with gateway server 126 directly. In addition, where UNIX-based casino, 
lodging, or event management systems are available, they may communicate directly with 
WAN 102. 

30 Also shown m Fig. 3 is a teieservices module 298 coupled to CPDB 220 through WAN 

102, Teieservices module 298 represents a telephone-based system that allows customers to 
arrange travel plans at some or ail of the affiliated casino properties. By connecting teieservices 
module 298 to WAN 102, operators can access customer data in CPDB 220 in real-time. 'T his 
allows operators to determine, for example, whether a customer arranging a trip to one of the 

35 affiliated casino properties qualifies for a comp room, a room upgrade, or the like. 

Customer accounts in CPDB 220 include detailed information on the customer's 
preferences, interests, credit rating, win profiles, and accumulated activity points. Win profiles 
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are determined according to gaming data accumulated ai any of the casino properties affiliated 
with the parent company through input devices such as slot machines 130 and dumb terminals 
1 32 associated with gaming tables 134. Activity points are determined in part by gaming 
activity but may also be augmented by sweepstakes and various other promotional programs. 
5 Other customer data relating to non-gaming activity may be tracked through various input 
devices, including workstations 12S, 148 supporting EMS 240 and POS 244. and made 
available to the marketing department for evaluation and analysis. These features of customer 
accounts are discussed in greater detail beiow. 

In order to provide rapid access to essential customer data while minimizing data 
10 storage requirements for casino properties, each CMS 234 maintains accounts for regular 
customers in a local data store. With this configuration. CMS 234 accesses CPDB 220 
whenever a customer registers activity in any of the casino venues and no customer account 
data is available locally. For example, when a customer presents his or her membership card to 
check into the hotel at the casino property, LMS 234 checks with CMS 234 for a local customer 
15 account. Currently, LMS 238 does not maintain a local data store, but if expanded to do so, 
LMS 234 would check its local data store before checking that of CMS 234. 

In general, customer data may already be available locally from CMS 234 if the 
customer has visited the casino property before or if. for instance, a new customer played slot 
machines 130 before checking in to the hotel. In the first case, static customer data, including 

20 the customer's name, address, credit rating and the like, would be maintained m CMS 234 from 
the previous visits. In the case of a new customer, CMS 234 will have already retrieved a 
summary of the customer's account data from CPDB 220, as described below, and LMS 238 
may access the data from CMS 234. 

If the customer data is not available Socaliy, as when a customer new to the casino 

25 property checks into the hotel first, LMS 238 will send a data request to CMS 234, which 

forwards it to CPDB 220 using the messaging system and transaction management system 216. 
216'. This transaction is carried out on-line in order to provide rapid access to a summary of 
basic customer information such as the customer's address, credit status, gaming points, 
theoretical win profile, and tecem trip activity. Ready access to this customer data allows 

30 casino employees to make the check-in process both more efficient and more personalized for 
the customer, enhancing the customer's overall experience and making him or her more likely to 
return. 

Throughout the customer's stay at the casino property, the customer's account will be 
updated to reflect the customer's activities at the various casino venues. For example, when the 
35 customer inserts his or her ID card into a slot machine 1 30, the ID number is read, the 
customer's betting activity is monitored, and the account updated to reflect the activity. 
Similarly, if the customer purchases an event ticket or redeems customer activity points for a 
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meal, workstations US. 148, respectively, provide the ID number and transaction data 10 CMS 
234. which updates the customer account to reflect the transaction. LAN 120 thus allows all of 
the customer's activity at the associated casino property to be tracked, which in curn provides a 
more accurate picture of the customer's value to the casino. 

5 The cross-property nature of system 100 makes the accumulated customer data available 

at whichever casino property the customer decides to visit. In order to maintain all account data 
up to date, all data processed by local management systems CMS 23-4, LMS 238, and EMS 240 
is periodically updated to CPDB server ! 12 in a batch process. This update synchronizes data 
in all storage locations, i.e. CPDB 220 and local stores associated with CMSs 234, to ensure 

10 that employees at any casino property have access to the latest data. When this configuration is 
employed with a WAN 102 having limited bandwidth, data synchronization is typically done 
when traffic on WAN 120 is low, in order to minimize any interference with on-line data access 
transmissions. 

Data must also he synchronized in the configuration of Fig. 2C, with central CMS 284 
15 periodically updating CPDB 220 from the data stores associated with LANs 120'. However, 
data traffic generated by these updates is limited to central LAN 120 and does not impact the 
data traffic on WAN 120. 

The seamless flow of data supported by the present invention reinforces the customer's 
perception of the national brand associated with the parent company and the activity point 
20 system provides additional incentives for the customer to patronize the casino's properties in 
different locations, in the absence of the method of the present invention, there is no record of 
the customer's activities at other casino properties and. consequently, there is no opportunity to 
leverage the data already accumulated on the customer to affirm the corporate links between the 
properties. 

25 Referring now to Fig. 4, there is shown a flow chart of method 400 in accordance with 

the present invention for tracking customer activity data and accumulating activity points across 
casino properties. For purposes of illustration, the discussion assumes that the customer 
activity data is being directed to CMS 234, i.e. gaming activity of some sort is being tracked. 
Method 400 is initiated when a triggering event, such as insertion of an ID card into a slot 

30 machine 1 30 or entry of an ID number or name into a dumb terminal 1 32 is detected 410. The 
customer ID number (or name) is read 420 by CMS 234, which determines 430 whether it has 
already activated the associated customer account. If the account has not yet been activated by 
CMS 234 at the current casino property, the customer account is activated 434 in CMS 234, a 
request for summary data from the. customer's account is forwarded 438 to CPDB 220, and the 

35 activated account is updated 442 with the summary data from CPDB 250. If", on the other hand, 
it is determined 430 that an account is already activated, the summary data is already available 
and the customer account is thereafter updated 444 to reflect any new activity, 
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h is noted That in the centralized configuration of system 100 (Fig. 2C), central CMS 
284 maintains data stores for each LAN 120 it handles. Consequently, the checking process 
described above occurs with centralized CMS 284 as well. 

Gaming and non-gaming activities are treated differently, and updates occurring at step 
5 444 typically include non -wagering activities related to gammg. For example, a customer's 
account may be updated at this point to reflect, redemption of activity points, redemption of a 
comp voucher, or currency or marker transaction (credit advance). In addition, some wagermg 
related data may be updated 444 at this time. For example, the start time of a betting session or 
the venue at which a wagering activity is occurring may be reflected to the customer's account, 

10 As noted above, activity point awards are based on a number of criteria and these may 

be adjusted to target different casino properties or venues. At step 448, method 400 determines 
whether the monitored activity is one for which any points are awarded. In the preferred 
embodiment of the invention, non-gaming activity, such a.s hotel and event activity, may be 
tracked for accounting and marketing purposes. Once non-gaming activity has been reflected in 

\ 5 the customer account, method 400 returns to await 4 10 the next triggering event. 

in the current embodiment of the invention, points are awarded for gaming activities, 
but this may be readily expanded to include point awards for non-gaming activities. With 
respect to gaming activities, points awards are determined when the activities are completed or 
an account status is requested. For example, when a customer initially inserts an ID card into a 

20 slot machine 1 30, method 400 will be triggered 410 to record the event. However, the activity 
points awarded are based in part on hnw much the customer wagers, and this is not determined 
until the customer removes his or her card from the slot machine 130 or an update request K 
received by SMS 262. If the current triggering event is. for example, a card removal or status 
request, the customer account is updated 450. Otherwise, method 400 returns to step 410 to 

25 await the next triggering event. For this reason, SMS 262 (Fig. 1 , 2B) maintains betting data 
until one of these events trigger it to forward the data to CMS 234 for updating the appropriate 
customer account. 

Referring again to Fig. 4, points are updated 450 when a betting session is completed or 
an account status requested, and method 400 checks 452 a table to determine the number of 
30 points to be awarded. For example, the company may promote a new casino property by 
awarding bonus points for all gaming activities at the new property, or the casino may award 
bonus points for gaming at a new venue that is being promoted. In any case, method 400 
determines 452 the appropriate point level and adjusts 454 the point tally in the customer's 
account accordingly. 

35 Betting activity is also reflected 458 in a separate field for purposes of determining a 

customer's comps. Unlike activity points, comp data is based solely on the historical amount of 
wagering done by the customer and does not reflect point weighting or other promotional 
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schemes. When any point and comp adjustments have been made, method 400 returns to await 
410 the next triggering event. 

CPDB updates 460 are required to synchronize data in the. embodiment of system 100 
employing distributed CMSs 234 and centralized CMS 284 (Figs. 2A and 28, and Fig, 2C. 
5 respectively j. In the former configuration, these updates periodically transfer accumulated data 
from all accounts in local management systems (typically, CMS 234) to CPDB 220. In the 
preferred embodiment of this configuration, updates to CPDB 220 are scheduled at least once 
every twenty four hours at time periods when activities on casino LANs 120, central LAN 1 10, 
and WAN 102 are low. Where WAN 102 has a high bandwidth, data updates may he made 
10 without regard to other traffic on WAN 102. For the reasons discussed above, CPDB updates 
from the data store of central CMS 284 do not. impact data traffic on WAN 1 02 and may be 
scheduled more flexibly. 

Method 400 balances the casino company's need for rapid on-line access to customer 
information from all of its casino properties with the personnel and monetary costs of 

15 maintaining multiple large databases. Instead of duplicating all customer accounts at all casino 
properties, copies of a customer's account are maintained only on central database server 1 12 
and in data stores of CMS 234, CMS 284 associated with those casmo properties visited by the 
customer. On the other hand, the data is available from central database server 1 12 whenever it 
is requested by another casino property. In the preferred embodiment of the invention, static 

20 customer data is maintained on local CMS 234 for a period of between six months and two 
years, depending on each casino's policy. If no activity is registered by a customer during this 
period, the local account may be purged. 

Computer system 100 and method 400 provide the infrastructure for a national customer 
recognition program for attracting and retaining customers. They aiso provide the raw customer 
25 data on which the casino company can base its marketing decisions and through which the 
company can launch new marketing programs. 

Customer recognition awards may be based on different subsets of customer data 
accumulated through and stored on system 100. The customer recognition program based on 
activity points has already been mentioned. A customer accumulates points in his or her 

30 customer account according to his or her activity at ail venues of all casino properties and 
according to any promotions currently being run by the casino or its parent company. The 
accumulated points represent a monetary value associated with the customer's activities and 
may be used in place of cash within any of me affiliated casinos. Thus, in addition to the 
already noted benefits of the point system, it contributes to the establishment of a cashless, 

35 paperless business environment. 

In order to provide an incentive for customers to accumulate points, points may be 
earned at any casino property affiliated with the company. The cross-property nature of point 

n 
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accumulation encourages customers to visit casino properties affiliated with the parent company 
when they travel since this activity contributes to their rewards no matter which casino property 
is the source of the points. Point awards may se structured in a variety of ways to target 
specific activities. For example, bonus points may be awarded to customers who visit a! least 
5 two affiliated casino properties within a given time period. Point awards may also be based on 
a tiered system, under which customers accumulate points for their gaming activities at rates 
that increase as their point totals increase, in general, point awards may be instituted for 
different time periods and for different, properties, according to the marketing goals of the. 
casino and the parent company . 

10 Accumulated points may also he redeemed at any casino property affiliated with the 

casino company. Using system 100, a casino employee can cali up data indicating the 
accumulated points of any casino customer, regardless of the property at which the points were 
earned and regardless of whether the customer is a regular at the casino property. For exampie, 
a customer who has been accumulating points through regular visits to a Las Vegas casino can 

15 visit an affiliated casino in New Jersey and redeem his or her accumulated points for goods or 
services at the New Jersey casino. 

Point awards also encourage customers to use their ID numbers at any of casino venues 
of the affiliated casino properties that offer customer tracking. This enhances customers' 
interest in participating in tracking programs and provides the casino company with more data 
20 on which to base its marketing decisions. Thus, the point system can be used to both recognize 
customers for their patronage and to market different facilities of the company. 

Comping is another customer recognition program that is supported by system 100 and 
method 400. Comps are awarded to a customer according to the customer's average daily 
theoretical win. which is an estimate of the casino's average daily winnings from the customer. 

25 The level of comps available to a customer is based on the casino's theoretical win from 

different gambling activities and the customer's historic level of these gambling activities. For 
example, on average a casino will win a statistically determinable amount of money, i.e. the 
theoretical win, from a customer who bets an average of $5000 per trip on blackjack. If the 
customer's theoretical win profile is large enough, the casino may "comp" the customer a free 

30 night's lodging, allowing the customer an additional day of gaming. Customer betting activity 
accumulated by system 100 is crucial to comping customers at a level commensurate with their 
expenditures, since it provides the raw data on the customer's betting activity. 

Casino employees have some discretion in awarding comps and the practice may vary 
from one casino property to another. System 100 helps eliminate some of the vagaries 
35 introduced by the discretionary nature of comping by providing the same customer data to 
employees at all casino properties visited by a customer. This ensures that comping decisions 
will at least be based on consistent estimates of the customer's average theoretical win profile. 
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Regular customers at one casino property of the company who visit a new casino property of the 
company are more likely to be "comped" at a level consistent with their play at then regulat 
casino property The national character of the present tracking system also means that the 
average dailv wager figure will include a iarger number of data points, since the customed 
5 gaming activities at all casino properties ate included. Estimates based on this data should be 
that much more accurate 

Customer data accumulated by system 100 ts also used in tracking customer offers to 
determine the validity of outstanding offers and the profitability of those offers for the casino. 
These offers can be entered into a customer's account to indicate then availability to tht- 

10 customer, and the customers account can be updated as necessary when an offer is redeemed 
in addition, data accumulated ir OPF>B 220 during the visit m which the customer redeems the 
offer can be used to determine whether or not it is profitable for the casino to repeat the offer or 
makt additional offers For example the casmn tnaj send to selected customers offers fot a 
free nights lodgmf as one of us properties if the customer stays for at least two nights. In 

! 5 certain cases, the customer's incremental expenditures tor the extra day s stay may not justify 
repealing the oftei to that customer. Information gathered on customer actmty associated with 
an otter rna> also allow the marketing department to better target their offers. 

Referring now to Fig. 5, there is shown a simplified block diagram of an alternative 
embodiment of system 100, in which both management system processing and database 
20 operations are distributed among LAN?; 1 20, This embodiment is illustrated usmg four LANs 
1 20( 1 }- 1 20(4) coupled to WAN 1 02, but the number of LANs ! 20 may be greater or less than 
this, 

LANs 120(1}~120(4> include local CMS 234(1)- 234(4), respectively, each of which has 
an associated local data store The local data stores of CMS 2^4( 1 > - 234*4) form the 

25 disfiibuted database for this embodiment of the present mvenoon Hach local data store 
comprises a local guest master list for toe corresponding casino property and a local crosy- 
leference list mat includes ^elected customer data from ever) other alhhaied casino property 
for example, the local guest maste- list of CMS 234{ 1) comprises data for ail casino customers 
who received their identitv cards a the associated casino ptoperty (property 1 s The local cross- 

30 jeterenee list of CMS 234( i > includes data sections tor properties 2. 3. and 4 . which comprise 
customer data for any customer that received their identity card at properts 2, 3. or 4, 
respectively, and subsequently visited property 1 CMS 234(1) also incudes virtual files 2, 3, 
and 4 for properties 2, 3, and 4, respectively, through whi^h data on customers who arc not 
listed m either the local master list o* local cross-reference list may he accessed In effect, 

35 virtual hies 2, 3, 4 on CMS 234{ 1 ) represent local master lists residing on CMS 234(2), CMS 
234(3). and CMS 234(4). respectm-h . that ate accessed by CMS 234< ! ) through WAN 102 
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In this embodiment of the invention, a customer of a casino is assigned an identification 
number including a proper!} tield that indicates the casino at which the cimoim-i s account 
originated, i e where the card was issued When a customer of property 1 uses his or her card 
at property ], the property field indicates to CMS 234( i } that the customer's account d,ita ix 
5 accessible thiough the iotal master list of CMS 234(1) On ttie other hand, when this customer 
visits proper!) 3, tiie pioperty field signals that CMS 234t3) should thee*, me data segment 
associated with pa">perty 1 m the local cross-reference list for the ..ustomei's at count If it is the 
customer' .s first visit to property 3. there will be no accourt data in the propeity 1 d*i<i segment 
of the l«K.al cross-reft rence list and CMS 2M(3) will use virtual file I to access the local mastes 
10 list of CMS 234( H. When tiie data is retries ed from CMS 2341 i ) it is stored in the property 1 
data segment of the focal cross-reiercnec list of CMS 2 *4(^, where it is updatee with the 
customer's activity during his or her visit to pioperty 3 

In the system of Fig 5. where a distributed database configuration is empioved, data 
s>nehroni?.ation is particularly important to ensure that all activity data, including points and 

15 cump availability, :s reflected m a customers account and is available at anv of the affiliated 
casino properties Fot example, when acustomei trom property 1 visits property 3. the data on 
the customer's activity at property 3 is added to his ot hot account in the property 1 segment of 
the ioea; cross reference list of CMS 234(3 > Data .synchronization ensures that this new data, 
including points or eomps that are earned or redeemed during ;he visit, is available when the 

20 customer visits any other property Synchrcwrzation mav be accomplished m a number of ways 
Fot example, the customer's accounts at each :-asmo property ma> he periodical} updated to 
reflect any attiwty recorded by the customer at an) uf the affiliated properties. »<> that each 
property visited b> the customs has a complete set or the latest data 

Alternatively, all changes to a customer's account on any guest master list may be 
25 periodical!) updated to the customer's pimctpal account, s e, the account a! the issuing property 
In this case, each visit to a diffeient propertv require"; updating of the customer account on the 
guest mastes list with t ; ie account data from the customer's pi mcipai account Piovided these ot 
similar procedures are implemented to ensure the coherency of the distributed database, the 
point and corap system mav be implemented in the manner described above. 

30 Theic has thus been disclosed a system and method foi collecting customer data across 

ail ot the casino properties of a companv, accumulating tiie collected data in a patron database, 
and making the accumulated data available at any casino property when triggered by a customer 
visit to the casino pioperty The system piuvides an intrastruaute fot implementing across all 
affiliated casino properties a point system that rewards customers for the gaming activities and 

35 allows utsgctmg of difiVient casino ptoperhes and venues fot marketing purposes The system 
also makes available to casino employees the same customer data, incenendent of which casino 
property the customer visits regularly. This allows customers to receive personalized service 
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and to be rewarded m accordance with their value to the casino even when visiting new casino 
properties. 

What is claimed is; 
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Appendix A 

This appendix describes, the messaging s\siem employed in the preferred embodiment 
of computet system J 00 < Fig 1 ; A numbering scheme is cmplosea in the appendix which n> 
different ftom that cmpimed m the bod) of the specification Correspondence between 
S different elements may be determined from Table AS In addition, corresponding element 1 , 
seivmg computable functions m the specification and appends aie indicated m Table A] 

Referring first to Fig Al, iheic is shown a block diagiam of a networked computer 
system A 100 that includes a messaging system A 120 for communications between application 
progtams on propnetarj and open system platforms Computer system A 100 comprises a fust 

10 computer A S 1 2 based on a piopnetarv system architecture, a server A 192 based on an open 
system architecture, and a gateway set ver Al ^2 tor connecting the different system 
architectures The proprietary s\ stern architecture of first compute! All 2 ts represented bv 
network protocol ALIO, and the open system architecture of server A 192 is repiescnicd b> 
network piotocoi A! 60 In the disclosed embodiment of s\ stem A 100, the open system 

1 5 architecture is UNIX, Windows, or the like, the network protocol A 160 is TCP/IP, the 

proprietary system architecture is IBM's System Network Architestuie iSNAi, and netwoik 
protocol M30 is IBM's SNA LUo.2 

First computer All 2 includes, an RPG application AUG, messaging system A 120, and 
network protocol Al 30 Messaging system A120 acts as an application prograrr interlace 

20 (API) between RPG application A 1 1 0 and a transaction management .system A 1 50 on gate wa> 
server 1 52 Transaction management s>stem 150, m turn provides access to transaction 
■services Al 7 0 on open system sei ves N2 Transaction services 170 represents the different 
senates that may be accessed by RPG application Al 10 and the means for accessing these 
services, 

25 Gateway server A 1 52 includes a network services module A i 40. transaction 

management system A 150, and an interface module A142. When triggered by messaging 
system A120, network service module A 140 allocates a conversation between messaging 
system Al 20 and transaction management sj stern A 150 by means of interface module A 142 A 
conversation is a logical connection thai allows communications between applications on 

30 different nodes to proceed, while hiding the details of the undeilymg communication prutoco, 
from the communicating applications. In the disclosed embodiment, the allocated conveisatton 
carries message packets between messaging s\ stein A 120 and tiansactson management system 
Al 50 using network protocol 1 30 The commumeat on link between RPG application Al 10 
and transaction services A 170 is completed b) a dialogue between transaction management 

35 system A 150 and transaction services A 170 based on network protocol 160 The message 
packets generated b> messaging system A 1 20 include parameter^, 1 1 data and control 
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information, necessary to activate one of transaction services A 170, carry on comrnunicatiorts 
with the activated service, and terminate it. 

Referring now to Fig. A3, there is a block diagram of a transaction service A 170. which 
comprises an instance of transaction management system A150, including a client-server 
5 interface (CSI.) A 154, a service application A3 10. a message conversion system A304. and a 
database management system (DBMS) A380. Service application A3 10 is a user provided 
module that includes functions for accessing data from DB A390 through DBMS A280. In the 
disclosed embodiment, DBMS A380 is Informix 7.0. and transaction management system A 150 
is AT&T's TOP END, both of which conform to the X'Open distributed transaction processing 
10 (DTP) XA interface. Transaction management system A 150 also conforms to the DTP TX 
interface for communications with service application A3 10. 

Referring now to Fig. A2, mere is shown a block diagram of messaging system A 120 
comprising a MSG module A210, a MSG Build/Parse module A220. a List..Build module 
A230, a memory management module A240, an inbound/outbound message buffer A218, and 
15 defmed data structures A250 for coupling data between messaging system Al 20 and RPG 
application Al 10. In order to make messaging system A120 portable between platforms, 
component modules A2 10, A220, A230, and A240 are written in the C programming language. 

MSG module A210 includes a MSG API A212 through which RPG application Al 10 
accesses functions A2I4 for initiating and terminating conversations with transaction 
20 management system A 1 50 and for requesting transaction processing services from server 
application^ A3 10 accessed through transaction management system A] 50. In the disclosed 
embodiment, MSG module A210 also includes registered functions A216, which manipulate 
data between defined data structures A250 and MSG buffer A218 as described below. 

Build/Parse module A220 comprises a Build/Parse API A222, a data dictionary (DD) 
25 A228, message building/parsing functions A224, and a registered function <RF) API A226. 
B hi Id/Parse API A222 provides MSG module A 210 with access to platform independent 
message building/parsing functions A224. DD A22S specifies the fields and field attributes of 
data segments that are recognized by an open system resource being accessed by RPG 
application A J 10. As discussed in greater detail below, DD A228 contributes to the flexibility 
30 of messaging system A 120, by providing a mechanism for altering its message building 

capabilities without requiring recoding of RPG application Al 10 or serve! applications A3 10. 

RF API A226 provides Parse/build module A220 with access to registered functions 
A216, which manipulate RPG data in defined data structures A250, Registered functions A216 
are specific to the data types of a platform, and including registered functions A216 in MSG 
35 module A2 30 removes any platform-dependence from Build/Parse module A220. For example, 
a substantially identical build/parse module A322 (Fig. A6) is employed by server application 
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At 1 0 on the open system platform Build/Parse module A320 parses request message packer 
from RPG application Al 10 ai d builds rt-spnnse message packets lo RPG application A 1 10 

LM_build module A230 and MMS module A240 provides ImkeJ list building and 
memory allocation functions, respectively, foi MSG module A210 and Budd/Parse modu e 
5 A220 Fo example, when RPG application A) 10 ts initialized, it identifies to MSG module 
A2 10 ail defined data structures it employs MSG module A2 10 cheeks that the defined data 
stmetures have the propei number of parameters and calls List build module A230 to generate 
a linked list of pointers to the defined data .structure-. Li*-i _budd module tails or MMS module 
A240 as needed to allocate memory for the linked list L:st„ Build module A230 and MMS 

10 module A240 aie also used by MSG module A210 to eliminate the linked list when RPG 
application A' 10 is termnated. 

Typical service applications A3 10 provide RPG application Al 10 with functions ioi 
searching and writing data to database A390 {Fig M; In order tor RPG application A 1 1 0 to 
communicate with database A390, messaging system A 120 must employ m it.s data packets, 

15 dau having attributes consistent with the columns of database A390 Since RPG application 
Al 10 ts the ultimate source of data, messaging system A120 mast include some means of 
ensuring consistency between ;he attributes o* the data segments- emploved by RPG application 
A110 and those o: database A390 This is the function of defined data structures A250 and 
DI>s A22B, A328. 

20 Messaging system A 120 provides utilities to: generating DD A22b and DD A328 ( Fig 

Ad) and defined uata structures A250 from a single source that includes attribute definitions 
consistent v> ith those of database A390 This ensures that messaging sy stem Al 20 and sen ice 
application A3 30 support the same vocabulary', which in turn ensures that RPG application 
AU0 and database A390 can communicate The single stance from which DDs A238, A32K 

25 and defined data structures A250 are generated ts ASCII definition file i ADF) A260 

Referring now to Fig. A4, there is shown a block diagram indicating the relationship 
among ADF A260, DDs A228, A3 28, and defined data structures A250 ADF A2o0 is a 
human-readable file that includes descriptions of the attributes of every field of even- data 
segment m the system As noted aho\e, trie attributes ol a segment correspond to the columns 

30 {attnbutcsl oi the database A390 ADF A260 also includes a header segments, v> Inch <ue used 
to indicate which service application A3 10 is being requested by RPG application Al 10 
Header segments include control mfoimation ior error codes and messages and those header 
segments associated with set vice applications A3 10 that lequue data input from RPG 
application Alio, nave appended the data segments couesuondtng to the required data ADF 
35 A ?60 also includes a list o£ restricted segments, which are segments that may only be used by 
selected service application.- A3 10 ADF A260 is typically generated through a GL 1 design 
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tool, which in the preferred embodiment of the invention, is Visual Builder Too) < VBT). In 
essence. ADF A 260 specifies the vocabulary understood by database A390. 

Also shown in Fig. A4 is a DataJStructure Utility (DSU) A270 which is used to 
generate defined data structures A250 from ADF A260 whenever ADF A260 has been 
5 modified. In particular, DSU A270 reads ADF A260 and uses List.. .Build moduJe A230 to 
generate a linked list of fields and a linked list of segments from the entries in ADF A260. For 
every segment in the segment linked list. DSU A270 retrieves attributes of the component fields 
from the field linked Jist and writes the information to a DDS A250. Defined data structures 
A250 are then written to a file, which is linked to RPG application Al 10 and messaging system 
10 A 1 20 as an external 1 y defined data structure. 

There arc two defined data structures for each data segment defined in ADF A260. 
Application request data structures t'ARDS; A252 are loaded with data by RPG application 
A1 10 to provide messaging system A120 with the data it needs to a build a message to a service 
application A3 10. Application response data structures (ASDS} A254 arc written by messaging 
15 system A 120 to communicate a response from service application A3 10 to RPG application 
Al 10, following parsing by Build/Parse module A220. An single application control data 
structure (ACDS) A256 is used by RPG application Al 10 to communicate service application 
requests to messaging system A 120. 

Also shown in Fig. A4 is a utility, DDBIN A280, that reads ADF A260 and generates 
20 DD A 228 as a binary file sorted by segment names. DDBIN A280 also creates a summary 
information field for DD A228, including the total number of segments, offsets into DD A228 
for alphabetically sorted segment groups, and an offset into the file for a restricted segment file 
(RSF)- DD A228 may be linked into Build/Parse module A22D as an include file. 
Alternatively, the contents of DD A228 may be read into a segment cache A325 (Fig. A6) 
25 associated with Build/Parse module A220, as needed, to facilitate access to segment 

information. This latter alternative is employed in messaging conversion module A304 (A3) 
which is used for message packet building/parsing by service application A3 10. 

Referring now to Fig. A5, there is shown a representation of an ACDS A256 that is used 
by RPG AUG to request services of messaging system A 120. ACDS A256 is also used by 
30 messaging system A3 20 to provide information on the status of requested services to RPG 

application Al 10, A single ACDS A256 is used by RPG application A 110 to indicate which of 
transaction services A 1 60 is being requested. Details of the requested service are provided in 
the following fields of ACDS A256: (1) Request Service Name. (2) Sending Segments, and (3) 
Hold Context Flag. 

35 Request Service Name is a field in which the name of a service application A3 10 

available through transaction management system A350 is specified. A corresponding header 
segment defined in ADF A260 is used by messaging system A 120 to indicate to transaction 
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management system A 150 the type of service being requested. As noted above, some service 
applications A330 require that RFC i application Al 10 provide data along with the service 
request In these cases, the Sending Segments field is used b\ RPG application to specif) 
uhsch ARDSs A252, if an) . contain the required data Each such ARDS A252 is specified in 
5 the Sending Segments field by the Segment Name of the data it contains.. In the preferred 
embodiment of the invention, the name of each data segment to be sent is concatenated and 
delimited b> a pipe ("!") For example, where data from three ARDS.s A252 corresponding to a 
name (NAME), business address (BUS), and home address (HOME) will be sent to seivice 
application A3 10 specified b> ACDS A256. the Sending Segment*, field will be 
{{) NAMEJBIJS1HOME. Data provided in response to a service lequest is sent trum service 

application A3 1 0 to messaging system A 1 20 as data segments Messaging system A 1 20 makes 
an) necessary data conversions and forwards the converted data segments to RPG application 
A110 using the corresponding ASDSs A254 

Hold Content Flag is set when RPG application A! 10 will retain an on going 
15 conversation with a .service application A3 10 as, for example, when RPG application A] 10 will 
submit sequential service calls to service application A3 10. 

The Results Services fields of ACDS A25fi comprises Return Status Code, initialized 
Flag, and Control Flag fields Messaging system Al 20 uses these to indicate to RPG 
application Al 10 the status of a sen ice request. Return Status Code is zero, unless an error has 
20 occurred in the Service Request. Initialized Flag is set when messaging system A 120 is 
properly initialised and is zero otherwise. Control Flag indicates the status of messaging 
system A 120 It is zero b\ default, tour wher a service application A3 10 is currently holding 
context, and some non-zero value other than four when a failure occurs in messaging system 
A 120. 

25 The interactions between RPG application A HO and messaging system A 120 will now 

be described from initialization through termination of RPG application A 1 10. As noted above, 
messaging system A120 is initialized through a function call from RPG application Al 10 
during its initialization. The initializing function call includes a parameter list specifying the 
segment name, segment address, and number of occurrences of each ARDS A252 and ASDS 

30 A254 used by RPG application Al 10 to send data to and receive data from MSG module A250, 
The parameter list also specifies the name and address of ACDS A256 used by RPG application 
A110 to communicate control information to MSG module A2I0. Addresses for ARDS A252, 
ASDS A254, and ACDS A256 (collectively, DDSs A250) are in shared memory location Al 14. 

On initialization, MSG module A210 first cheeks that DDSs A250 are specified 
35 properly (3 parameters for each ARDS A232 and ASDS A254 and 2 parameters for ACDS 
A256). MSG module A2K) then calls initializing functions in Build/Parse module A220, 
ListJ>uild module A230, and MMS module A240, initializes a conversation with transaction 
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management system Al 50 via network services A3 40 and IF A 142, and waits for a verification 
message that the luuveisatioo has been established A* this time, transaction management 
system A150 establishes, a dialogue Vvitn transaction seiY!ce<- A160 on open system server 
A! 92 MSG module A2I0 then calls LiStJBuild module A230 to generate a linked list of 
5 pointers to DDSs A250, and ListJBmid module A2W cull;- MMS module A240 as needed to 
allocate memory tor the linked list. 

Once conversation/dialogue imks htve been estabhshed between messaging system 
A120 and transaction management system A150 RPG application Al 1 0 accesses a ieqnesn*d 
service application A3 10 of transaction services A 160 through transaction management system 

10 Ai50, using messaging system A120 as an application program interface (API) RPG 
application A 3 10 initiates a request tor services by loading the Request Service Name and 
Sending Segments Lis: fields of ACDS A 2*5(1 with the segment name of the service being 
requested and the segment names of any da:a being sent to the requested service RPG 
application Al 10 also load* each ARDS A252 named on the bending Segments List with the 

15 data to be sent. 

When ARDSs A252 and ACDS A2^o are loaded, RPG application 41 10 calls the 
request function in MSG module A210. including the names of ACDS A256 and ARDS A252 
m a parameter iisl associated with the function call MSG module A2 10 use the request 
function to clear the Results Services fields of ACDS A256 and read the Request Service 

20 Names and Sending Segments Last fields at ACDS A2^6 MSG module A21 0 writes a 

control/status header \ see beiov; ) to message buffer Al 3 8, specifying Request Service Name, a 
user identification tusend), and status data lor transaction management system A 150. MSG 
module A210 also calls the BtitSd MSG function in Bmld/Parse module A220 wah the 
parameter fist specsfyirg the names of the data segments and the location of message buffer 

25 A218. 

Ru'ld'Parsc module *\220 handles the conversion and manipulation of data between tnr 
DDSs A250 identified m the parameter list and message buffer A218. As noted above, the 
Build/Parse MSG function*, of module A220 use registered functions A216 to accomplish the 
actual data manipulation between DDS>- A250 and message buffer A2 1 8 For outbound 
30 messages, the Build MSG function uses DL> A228 to determine the required form for each 

segment to be included in the message packet and makes the necessar> format conversions DD 
A228 is also used on inbound message packets to convert data to a format appropriate to the 
operating system of the AS/400 The addresses of DDSs A250 are determined from the link list 
generated on initialization. 

35 The message packet generated by messaging system A120 has the following form: 

(I) I error 1 control 1 function code i userid i data t. 

< control/status » 1 < — - application data — > 
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The header, comprising error, control function code, and userid field;., provides the routing and 
status information necessary to transfer the service request and associated data of RPG 
application A1 10 from messaging system A 120 to requested service application A3 10. In 
particular, the error field includes error codes for tracking purposes, the control field specifies 

5 the status of communications with transaction management system A 130, the function code 
field specifies which service application A3 10 is being requested, and for security cheeking 
purposes, userid identifies the personts) using RPG application A HO. The data field comprises 
the service name and any application data, suitably formatted, thai is being u ansfened between 
RPG application Al 10 and service application A3 10. As discussed above, this data is loaded 

10 by messaging system A 120 using Parse/Build module A220. 

Once the message packet has been completed, MSG module A210 calls a send/receive 
function to forward message packet to transaction management system A 150 in gateway server 
A 152. using the conversation allocated on initialization. Interface module A 142 maps the 
conversation to the dialogue established between transaction management sy&tem A 150 and 

1 5 transaction services A 1 60, determines from the function code in the header of message packet 
(1) which service application A3 10 is targeted, and uses transaction management svstem A 1 50 
to call targeted service application A3 10. 

Referring now to Fig. 6A, there is shown a detailed block diagram of message 
conversion module A304 composing a message build/parse module A320, a lis!„buiid module 

20 A3.30, and a memory management system (MMS) module A340, which perform functions for 
the open system platform of server A192 that build/parse module A220, hst„bmld module 
A230, and MMS module A240 perform on the proprietary platform of AS/400 Ai 1 2. In the 
case of server A192, however, transaction management system A 1 50 operates in conjunction 
with CSI A154 to handle touting and control information, hi parttoilai . these components 

25 ensure that the data portion of message packet (I) is routed to service application A3 10 

Consequently, there is no need for a counterpart of MSG module A210 on server A 192. On the 
other hand, the data portion of message packet (i) must be converted into a format suitable for 
the open system platform, and this is the function performed by modules A320. A330, A340. 

As indicated in Fig. 6A, service application A3 10 has associated registered functions 
30 A3 J 6 that isolate platform-independent, buiid/parse module A320 from platform specific 

message (MSG) buffers A3 14, A3 IS. In this case, MSG buffer A214 includes data structures 
for coupling data between message conversion module A304 and DBMS A3S0 in a format 
consistent with that of database A390, MSG buffer A2I8 provides a buffering function for 
message packets inbound from transaction management system A 150 and outbound to 
35 transaction management system A 150. List..miild module A330 and MMS A 340 also provide 
essentially the same functions as then counterpart modules A230, A 240 on AS/400 Al 12. 
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Message conversion module AW also differs from messaging system A120 m that it 
um:s a segment cache A354 and segment i aihe mtcitaic stiuctuif (SOIS) A35? tr> t,.nfitate 
at ccs 1 - :o the information data dictionary (DD) A32b without including the enttte file m 
Build/parse module A220 SOS A352 includes information tor tracking accessed data 
5 t.egmcn:s in segment cache A354 This is an altern itivc configuration to that employed on 
AS/400 Alii, but it requires sufficient rnemoty foi segment cache A3 54 

While the configuration of computer system A100 shown in Fig Al provides the 
nccessa-y communication between an RPG application A! 10 and transaction services A170. u 
does not provide security or accounting Junctions where transaction management ssstem A 150 

10 is TOP END tTEt an 1 TF A J 42 is an inbound agent (IA) spawned by network services module 
A14t> when messaging system A120 is initia'ized In particulai, IA A142 is configured to map 
ail conversations/dialogues having the same transaction ptogram name (TE sign-on name) and 
transaction code (Request Service Name) to a generic usend Consequently, all uset 1 of a given 
set vice application 310 will be ?ss gned the same usend independent of which uscr<s) of RPO 

3 5 application Al 10 actual!) initiated the transaction If not addiessea, mis circumstance 
eftecti\el\ eliminates security checking and accountability tor tratisactions to server A 192 

in order to ensure both stcuntv checking and accountability for transactions to server 
A1 Q 2. die preferred embodiment of system A. 100 incorporates a security seivia. (SiGNON 
SfcC'URIf \ SERVICE, SSbl AIM m the TE transaction management system A 15(* on gatewas 
20 server A152 Refenmg now to Fig A7, tiiete is show i a block dugiam of a ptefened 
(.onfiguution foi gateway ^ersc Alf 2, m which trans - action management system A150 is 
(. onpled to ti attraction services A 1 1)0 through SSS A 1 54 SSS A \ 54 comprises a T'ii client 
A156 and a TE seiver Al V coupled back-to back through a chent/servei interface <CS1) 
piovided by transaction management svstem A 150 

25 1A AI42 incorporates an integral client which accesses SS*S A154 through transaction 

management system Al 50 on behalf of messaging system A120 On initialization of messaging 
system A 120, network services module AK0 spawns iA A 142. which forwards a SIGNON 
message, including a non-geneuc usend to transaction management system A150 IA A142 
establishes a dialogue with SSS A 1 54 by passing a request for SSS services through transaction 

30 management system A150, using the genenc t'send piouded ir the configuration file of IA 

A542 Transaction management system AI50 forwards the request to SSS A154. establishing a 
dialogue between. Tfc server A 15b and RTO application A1K) !\ ja messaging s>siem A120* 
TH server A! 56 then triggers TE client A156 to sign onto transaction management system 
A' 50 nstng ihc non-genenc usend embedded in the signon message SSS A. 154 confirms to 

35 messaging svstem A 120 that the dialogue has been established and sets ^ flag holding the 
dialogue open Theieafter, transaction seiwces A 170 aie accessed oy TE client Al 56 tn 
response to message packets (I) from messaging .system A 120. 
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TABLE A 1 

Specification AjRJKlulte 

transaction management sysicm i 16, ! }6' transaction management system i 50, 1 50' 

gateway server i 26 gateway server 152 

database server 1 1 2 «pen system server 192 

computer 124 computer 112 

DBMS 214 DBMS 380 

CPDB 220 DB 290 

LAN/WAN IF 280 network services 140. 1A 142 

TCP/JP protocol module S 60 

SNA L06.2 protocol module 1 30 



26 



WO 97/44750 




27 



WO 97/44750 



r 







Aai2 

MSG API 






214 










A218 | 
Msg Buffer j 


inSializ© 
Rsqoast 


Pars© 




Terminate 


1 


1 


A2t6 




Bum 


Bfiafl.Fvnctjgns. 


Inbound 
Parsed n«ta 


Put Data 




Outbound 
RPG Data 


Get Data 
language 








FQfTTKti 








Validate 


All 4 
Shared Memory 


^ A250 


DOS / 




Fig. A2 



28 



WO 97/44750 




Fig. A3 



29 



WO 97*44750 




30 



WO 97/44756 



PCT/US97/69S63 



ACDS 

Request Services 
Request Service Name 
Sending Segments 
Hofd Context Hag 



Results Services 

Return Status Code 
Initialized Rag 
Control Rag 



Fig. AS 



31 



vcrtvssrrmm 



A312 
Application API 



Application 

Function 



A316 

Rgg'd Functions 

Put Data 
Get Data 
Language 
Porrnat 



A344 
MMS 



A334 
Fqnctbns 

fnUatize iist 

Set free function 

Set Key Type 

A332 
ListJ3utld API 





A322 




Build/Parse 




APi 




A324 




FMnctipn$ 


R 


Initialize 


F 






Build Msg 




P 

! 


Pill Cache 




Parse Msg 




Fig. A6 

32 



WO 97/44750 




WO 97/44750 PCT/US97V09863 

Claims 

1 . A method for rewarding customer patronage at a plurality of casino properties, the 
method comprising the steps of; 

assigning an identification number and an associated account to a customer; 
5 monitoring the customer's betting activity at each of the plurality of casino 

properties; 

accumulating points in the associated account according to the monitored betting 
activity: and 

accessing the customer's account at any of the plurality of casino properties to 
10 determine the points accumulated. 

2. The method of claim 5 , comprising the additional substep of redeeming the accumulated 
points for awards determined by a number of accumulated points. 

15 3 . The. method of claim 2. wherein the step of redeeming accumulated points comprises 
redeeming accumulated points for gifts or services provided by the casino property. 

4. The method of claim I , wherein the step of accumulating points comprises the subsets 
of: 

20 assigning point values to betting activities according to selected criteria: 

determining which of the selected criteria are met by the customer's betting 
activity: and 

accumulating points in the customer account according to the determination. 

25 5. The method of claim 4, wherein the step of assigning point values comprises the step of 
assigning points values to a betting activity according to at least one of a time, a venue, and a 
casino property at which the betting activity occurs. 

6. The method of claim 1 . including the additional step of recording the 'customer's 
30 monitored betting activity separately for each visit to one of the casino properties for use in 

determining a theoretical win profile for the customer. 

7. The method of claim 6, including the. additional step of displaying the customer's 
theoretical win profile when prompted by a casino employee. 

35 

8. A method for tracking customer activity at a plurality of casino properties wherein each 
casino property includes a computer-implemented management system and at least one input 
device, coupled to the management system for transferring customer activity data from a casino 
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venue to the management system, the management system of each casino propetty being further 
coupled to a central database server, the method comprising the steps of: 

assigning a customer ID and a corresponding customer account to each customer 
of the plurality of casino properties; 
5 forming a database of customer accounts in the centra] database server, each 

customer account being accessed through the corresponding customer ID; 

monitoring the input device at a casino property for customer activity data, 
including a customer ID; 

when a customer ID is detected, determining whether the corresi?onding 
10 customer account has been activated in the management system of the casino properly ; 

when the associated customer account is activated, updating the activated 
customer account with the customer activity data from the input device; and 
when the customer account is not activated; 

copying selected customer activity data from the corresponding customer 
15 account in the central database to activate the customer account in the 

management system; and 

updating the activated customer account with customer acuvity data from 
the input device. 



20 9. The method of claim 8, wherein each step of updating the acti vated customer account 
comprises updating activity fields of the activated customer account at cording to the customer 
activity data from the input device. 



10. The method of claim 9, wherein the step of updating activity fields comprises the 
25 subsets of : 

identifying an activity characteristic from the customer activity data; 
determining a number of activity points from the activity characteristic; and 
adding the determined number of activity points to a field of the customer 
account associated with the activity type. 

30 

1 1 . The method of claim 10, wherein the activity characteristic comprises an activity type 
and an activity level. 



12. The method of claim 9, wherein the copying step comprises the subsets of: 
35 retrieving selected customer activity data from the corresponding customer 

account in the central database; and 

writing the selected customer activity data to an account in the management 
system indexed by the corresponding customer £D. 



35 



WO 97/44750 

\ 3 . The method of claim 8, 
patron database with customer ; 
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, including the additional step of periodically updating the central 
account data in the management .system of the casino property. 



i 4. The method of claim 8, composing the additional steps of; 
5 determining whether a display device is associated with the monitored input 

device; and 

transmitting the selected customer activity data from the activated customer 
account to the associated display device when such a device is present. 

10 15. A method for making customer account data collected at one or more casino properties 
of a company available at another casino property of the company, wherein each cast no 
property is coupled to a management system for tracking customer activity data accumulated 
through at least one input device in the casino property and wherein the management system is 
further coupled to a central database, the method comprising the steps of: 
15 issuing to each customer of the company a customer ID number for identifying 

an associated customer account; 

adding the customer accounts to the central database; 
retrieving selected customer activity dam from a customer account when the 
associated customer ID number is input to the management system; and 
20 adding any new customer activity data input io the customer account associated 

with the customer i'D through the management system. 

1 6. The method of claim 15, comprising the additional step of assigning activity points to 
the customer account associated with the customer ID when the customer activity is gaming 

25 activity. 

17. The method of claim 1 6, wherein the assigning step comprises the sub-steps of: 

determining a type of gammg activity; and 

assigning a number of activity points according to the type of gaming activity. 

30 

1 8. A system for tracking customer activity at. a plurality of casino properties associated 
with a casino company using customer accounts indexed by customer IDs, the system 
comprising: 

a locai computer system at each of the casino properties; 
35 at least one input device at each casino property and coupled to the local 

computer system for transmitting customer activity data, including a customer ED. to the 
computer system; 

a management system coupled to each of the local computer systems for 
receiving customer activity data from the coupled input devices, the management system 
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being further coupled to a central database tv: retrieving selected customer activttv data 
fiom the central database when netesi>a!}, and updating the selected cusfomei JUfvu^ 
data with the received customer activity data from the coupled input device and 
the centu 1 ('.it ihase eompnstng custumei ai. counts fot the atatmneis of the 
5 Las.no compan) and a database management piogtam for recen mg eustomei aem itv 

data noin thr management system updating tlx- eential crstuner a*, counts of the centtai 
database to reflect customer activity data at am of the cavno properties, and providmc 
selected customer activdv data to a local computer -.vsten through the management 
system coupled to the hval computer svstem 

10 

19 I he svt.tem of claim 1 8, wherein there are a pluraHv of input devices located at \ a? sous 
venues of at ieas; one casino property and the venues, tnclude siot machines, gaming tables, 
restaurants, reun sales loca ions, hotel check in locations, and othei servic. lucations 
associated with the casino property. 

15 

20 The sjstuu of claim W wherein the plurahtv ot input devues include caid reader-., 
dumb terminals, and work stations 

21 The svstem of cliini 18, wherein the customer aeti\ its data includes act vtfv type data 

20 

22 Tht system of claim 21, wherein the customer account includes, fields to retlcct different 
types of customer activity . 

23 The system ol claim 22 wherein each customer at count includes a gaming held m u fuch 
25 customer activities associated with slots, gaming tables, and other gaming sites are tracked 

separately. 

24 The system ot claim 23, vvhciem each customei account includes an activity points held 
to which points are added when customer a-itvttv is registered in the gaming field 
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